home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 644 < prev    next >
Encoding:
Text File  |  1996-08-06  |  1.4 KB  |  34 lines
  1. Newsgroups: comp.std.c
  2. Path: howland.reston.ans.net!torn!sq!msb
  3. From: msb@sq.com (Mark Brader)
  4. Subject: Re: Restrictions on qsort compare function?
  5. Message-ID: <1996Mar24.071329.24975@sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <4iokop$h4p@lyra.csx.cam.ac.uk> <mjs.827419998@hubcap> <mjs.827424727@hubcap>
  8. Date: Sun, 24 Mar 1996 07:13:29 GMT
  9.  
  10. > >             It would surprise me not at all if qsort() relied on
  11. >                                                          ^^^^^^^^^
  12. > > sort_func() having the property that
  13. > 
  14. > >    !!sort_func(p1, p2) == -1 * !!sort_func(p2, p1)
  15. > 
  16. > Of course, in comp.std.c, I should have said "...were permitted to rely on..."
  17.  
  18. Better yet, you should have not have assumed that !!x would produce -1
  19. when x < 0.  <grin>
  20.  
  21. Incidentally, I have encountered code where the comparison function for
  22. qsort() actually WAS specified with a return expression like *a < *b that
  23. produced 0 when it should have produced -1.  The interesting part is that,
  24. on the particular machine the programmer had been using, the sort worked
  25. correctly.  Evidently this particular qsort() implementation only tested
  26. whether the comparison function returned a positive value or not.
  27.  
  28. -- 
  29. Mark Brader, msb@sq.com, SoftQuad Inc., Toronto
  30.         "I'm a little worried about the bug-eater," she said.  "We're embedded
  31.         in bugs, have you noticed?"             -- Niven, "The Integral Trees"
  32.  
  33. My text in this article is in the public domain.
  34.